An IWF device is a data intercommunication device in a wireless network, through which the wireless network is capable of implementing interaction of IWF service data with a different network, such as a PTSN (Public Switched Telephone Network), etc. The IWF services include asynchronous data service, PC facsimile service and analog facsimile service. As illustrated in FIG. 1, the asynchronous service refers to transmission and receipt of texts and files on a PC1 and a PC2 with the use of “Hyper Terminal” or alike, the PC facsimile service refers to implementation of a facsimile service on a PC using a facsimile software such as WinFax or the like, the analog facsimile service refers to implementation of a facsimile service through a connection of a facsimile machine with a fixed station (a terminal in the wireless network). The “Hyper Terminal” refers to a program, which can be invoked for a connection with another computer, an Internet remote login site, a BBS (Bulletin Board System), an online service and a host if a Modem or a Null Modem Cable is used.
The 3GPP2 has defined a standard supporting the asynchronous data service and the facsimile service in a CDMA (Code Division Multiple Access) system. In the protocol stack as illustrated in FIG. 2, asynchronous data and applications of facsimile in the application layer are borne through the TCP (Transmission Control Protocol)/IP (Internet Protocol)/PPP (Point to Point Protocol), wherein these protocols can be terminated at a fixed station MT2 and an IWF device. The fixed station MT is a terminal incapable of data processing, and hence has to be connected with a terminal device to enable the data processing. For instance, the fixed station can be connected with a facsimile machine to enable the facsimile service, and with the PC software “Hyper Terminal” to enable the asynchronous data service.
The IWF device can be located at a BSC (base station controller) or an MSC (Mobile Switching Center).
In the case that the IWF device is located at the BSC, the IWF device can accomplish a switching between the asynchronous data/facsimile applications borne through the TCP/IP/PPP and PSTN data/modulated facsimile data. The PSTN data/modulated facsimile data can be borne via a service interface between the BSC and the MSC, such as an A2 interface. A protocol stack for the A2 interface is illustrated in Table 1 with a bearer rate of 56/64 Kbps.
TABLE 156/64 Kbps PCMDS0
In the case that the IWF device is located at the MSC, a logic interface between the BSC and the MSC, such as an A5 interface, can be used for transmission of the byte stream of the asynchronous data and facsimile data, and the ISLP (Intersystem Link Protocol) can be borne via the physical interface A2 to achieve a rate adaptation from air-interface data to 56/64 Kbps. The protocol stack for the A5 is illustrated in Table 2.
TABLE 2Data Octet StreamISLPDS0
In the case that a TDM (Time Division Multiplexing) system is used for transmission, a dedicated link of 56/64 Kbps is assigned for each user at A interfaces including an A1/A2/A5 interface, wherein the A1 interface is used for transmission of signaling, the A2 interface for transmission of voice data, and the A5 for transmission of the IWF service data. A bandwidth will still be occupied even if there is no data for transmission, thus resulting in a low utilization rate of bandwidths.
For improving the utilization rate of transmission resources of the A interfaces, the 3GPP2 has established a new standard IPizing the A1 interface/the A2 interface borne in the TDM system. That is, an IPized interface can be used for transmission of signaling and user data. User data can be borne through the IP/UDP (User Datagram Protocol)/RTP (Real-time Transport Protocol). Furthermore, a transcoder TC can be located in a core network, and thus instead of a 56/64 Kbps PCM code signal stream, an encoded/decoded data stream output from the transcoder TC can be borne on the RTP.
As obvious from the above, in the case of data transmission through the TDM, the bandwidth occupied for a user is a slot of 64K prior to IPizing the A interfaces. After the IPization of the A interfaces, the A interfaces can be enabled in a packet-switching way, and air-interface encoded/decoded data output from the transcoder TC can be transmitted, which is free from conversion into a 64 k PCM signal by the BSC. The air-interface encoded/decoded data has an average bandwidth of less than 8K, thus can save the transmission resources and greatly decrease the demands for transmission bandwidth of the A interfaces in comparison with the 64K bandwidth of the A interfaces prior to the IPization.
Although the IPization of the A1/A2 interface can decrease the demands for the transmission bandwidth of the A interfaces, the 3GPP2 has no definition of a bearer format (including protocol stack for the A5 interface, an RTP payload format, etc.) for the IWF data. The corresponding relationship between the defined standard service type and the RTP payload type is illustrated in Table 3, including Bearer Format IDs, Encoding Names, RTP Payload Types and Descriptions. Here the standard service type does not support bearing of an IWF service.
TABLE 3Bearer FormatEncodingRTP PayloadIDName6Type Value7Meaning0PCMUStaticMu-law (G.711)per [43]1PCMAStaticA-law (G.711) per[43]2QCELPStaticHeader-fullQCELP [IS-733]per [44]3EVRCDynamicHeader-full EVRCper [45]4EVRC0DynamicHeader-free EVRCper [45]5SMVDynamicHeader-full SMVper [45]6SMV0DynamicHeader-free SMVper [45]7telephone-eventDynamicDTMF digit & toneevents per [46]All other values reserved
In the case of data transmission with the TDM, the IWF data can be adapted to 64K by means of the protocol of ISLP borne via the A5 interface, and then be borne in 64K slots of the TDM. Since the 3 GPP2 has no definition of the bearer format (including protocol stack for the A5 interface, RTP payload format, etc.) for the IWF data, the IWF service data can not be transmitted to an IWF device, and consequently the IPized A interface is incapable of supporting the IWF service.
Obviously from the above, no bearer format for IWF data has been defined for the A5 interface by the 3GPP2 in the related art, and consequently an IPized A interface is incapable of supporting the IWF service.